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The current Johnson Space Center (JSC) Mission Control Center (MCC) Video Transport System (VTS) 
provides flight controllers and management the ability to meld raw video from various sources with telemetry 
to improve situational awareness. However, maintaining a separate infrastructure for \ideo delivery and 
integration of video content with data adds significant complexity and cost to the system. When considering 
alternative architectures for a VTS, the current system’s ability to share specific computer displays in their 
entirety to other locations, such as large projector systems, flight control rooms, and back supporting rooms 
throughout the facilities and centers must be incorporated into any new architecture. 

Internet Protocol (IP)-based systems also support video delivery and integration. IP-based systems generally 
have an advantage in terms of cost and maintainability. Although IP-based systems are versatile, the task of 
sharing a computer display from one workstation to another can be time consuming for an end-user and 
inconvenient to administer at a system level. 

The objective of this paper is to present a prototype display sharing enterprise solution. Display sharing is a 
system which delivers image sharing across the LAN while simultaneously managing bandwidth, supporting 
encryption, enabling recovery and resynchronization following a loss of signal, and, minimizing latency. 
Additional critical elements will include image scaling support, multi-sharing, ease of initial integration and 
configuration, integration with desktop window managers, collaboration tools, host and recipient controls. 

This goal of this paper is to summarize the various elements of an IP-based display sharing system that can 
be used in today’s control center environment. 

I. Introduction 

A s the Mission Operations Directorate (MOD) looks for innovative ways to reduce the sustaining cost of its 
facilities, the MOD Operations Technology Facility (OTF) was requested to study the feasibility of alternative 
architectures for the video transport system (VTS). Most data seen by flight controllers consists of text and 
graphics. However, motion imagery is used as well and is delivered through the VTS. The current VTS is built of 
broadcast quality hardware and video cabling and requires specialized maintenance and support. 

The current VTS satisfies the MOD requirement that a given computer display can be shared to other displays, 
such as the large projectors in the Flight Control Rooms (FCR), or a Picture-in-Picture window within any console 
position workstation. Any alternative architecture for the video system must at least satisfy this requirement. 

A preliminary list of requirements for Display Sharing also includes 

• The ability to share a screen or application in a one-to-one, one-to-many or many-to-many fashion 

• The ability to scale the image based on the target’s screen resolution and size 

• The ability to easily configure and operate the display sharing system 
• The ability to maintain a high level of performance and security 

Display Sharing is not intended to be an alternative to straight IP video systems; Display Sharing delivers more 
than mere video. There are many ways to deliver imagery over IP. For example, the OTF uses commercially 
available third-party tools to share imagery through a remotely accessible session for X-Windows applications. 
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This paper will review the existing MOD video infrastructure, the design approach that guided development of 
selection criteria, customers that have asked for specific requirements, the selection process which led to one 
product chosen to execute the Display Sharing prototype, a summary of this prototype process, and some final 
thoughts on the entire system. 


II. Existing Video Infrastructure 


Today’s MOD video switching system includes 
analog and Serial Digital Interface (SDI) devices 
with BNC connectors and RF coaxial cabling and 
links a variety of sources ranging from standard def 
and high def cameras from ground systems or via 
space link. The video switching system can route 
multiple video inputs to a single recipient, or a single 
video input to multiple recipients. The video 
switcher is centrally located and all input sources and 
all recipients are connected to it. This system is 
illustrated in Fig. 1 . 


A switcher generally supports a single switchable 
format but may have the ability to convert multiple 
formats or multiple versions of a single format. 

Since there is likely to be different input formats and 
the recipients will generally require different types of 
output, external converters, video scalers, encoders 

and decoders may be required to match the inputs to the switchable format and to match the output to the recipients. 



Fig. 2 provides an overview of the delivery of video to the control center or office environment via the existing IP 

infrastructure. 

Generic Video IP Switching System 

The basic capabilities of MOD’s current 
analog/digital video system can be replicated with 
a well developed and secured IP video 

infrastructure. One major drawback of standard 
IPTV solutions is that they do not include the 
ability to share a given display directly to a 
specific target (the FCR projectors for example). 
This functionality must be added separately. 

III. Design Approach 

A prototype was developed to test and 
understand the possibilities and options available 
to share displays with other workstations. 
Prototyping is distinctive from a trade study. With 
a trade study specific requirements are defined, 
prioritized and weighted. A prototype on the other 
Figure 2. Typical IPTV hand, uses a current commercial off the shelf 

(COTS) product to demonstrate the feasibility of using a specific product to meet requirements. As with most 
prototyping here in the OTF, a preliminary review of freely available tools and a comparison of vendor-provided 
data and analysis was made to select a specific product. 



Legacy Camera 


Server; Works tati o n/ Videc 
On Demand/etc. 


The objective was to prototype a method of sharing a display or specific application from one workstation to 
another within the MCC. The capabilities of the current VTS were surveyed to seed a list of requirements. The 
requirements were further refined to include security requirements necessary to ensure robustness and integrity. 
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Only pure software solutions were considered. Hardware-based solutions, such as video teleconferencing or 
IPTV, can offer viable alternatives to software-based display sharing. However, due to the hardware expense 
involved these options were excluded. A comparison of hardware vs. software solutions adds complexity and was 
beyond the scope of this effort. 

3D rendering capability was beyond the scope of this prototype development due the additional cost of rendering 
tools as well as the limited time available to do development. However, this functionality is feasible for display 
sharing and an option for future enhancement. 

Sharing information (whether a specific user application or an entire display) is often cumbersome to implement 
for both system designers and users, particularly where there is a requirement to share across operating system 
boundaries (Mac, Linux, Windows). This impacts display sharing application design. Attributes such as ease of 
operations, broadcast and multicast capability and, security are easily evaluated. Application performance can be 
difficult to measure, even with specific network bandwidth and local machine tools. The most difficult requirement 
to satisfy was the ability to share an application across different O/S platforms. 

Ideas for requirements are often drawn from the features of a given vendor’s product. However, requirements, 
when properly written, must be vendor-agnostic. The requirements for this prototype are grouped in the following 
areas. 

A. Ease of operation to users 

B. Configuration setup 

C. Security 

D. Group membership 

E. Sharing displays with other operating systems 

F. Manipulate the display 

G. Communication protocol 

H. Scalability from a host to a client 

I. Recording and playback sessions 

J. Application sharing versus desktop sharing 

K. System administration functions 

L. Performance 

M. License and Cost 

N. Handling Host Inactivity and Disconnections 

A. Ease of operation to users 

Users shall be able to easily share a display, whether within an O/S family or from a workstation running one 
O/S to a workstation running a different O/S without the aid of the administrator. 

B. Configuration setup 

The sharing application shall be configurable by an administrator. An administrator shall be able to manage user 
accounts and permissions as well as set up default configurations via a central management console across the LAN 
and WAN. 

C. Security 

The sharing shall support encryption for text and graphics. In addition sharing must adhere to all NASA security 
requirements governing firewall and network traversal among different O/S platforms. Use of a virtual private 
network (VPN) for sharing must not enable a user to circumvent NASA VPN security. Security measures applied at 
the application level shall apply to all child windows and dialogs. 

D. Group membership 
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Authentication shall support Lightweight Directory Access Protocol (LDAP), or of Active Directory (AD) for 
single sign-on. Active Directory allows the implementation of Organization Units (OU) to define groups of users. 
Export control review may be necessary to verify that groups do not contain ineligible individuals. 

A user shall have the capability to share applications to such groups. A user shall also have the ability to 
broadcast or multicast, through a secure port, without any group membership required of the recipients (although the 
content may be subject to export control). There shall be no theoretical limit to the maximum number of individuals 
or groups of individuals that can share applications or displays, although there may be a practical limit due to local 
machine resources and network bandwidth. An administrator shall have the ability to add or change group 
member’s settings for managing the process. An administrator shall also have the ability to grant access to any 
individual within the already developed shared group. 

E. Sharing displays with other operating systems 

As sharing may be required between various O/S platforms including Microsoft Windows (32- or 64-bit), Linux 
(32- or 64-bit) and MAC, security vulnerabilities that may exist when crossing platforms must be addressed. 

F. Manipulate the display 

The host (sharing) user shall be able to control whether a shared display or application is read-only or read/write 
for the recipients. The area shared is also known as the “active real estate”. For collaboration support, the system 
shall provide the ability for a client user to mark up the shared application. 

1 . Viewing shared applications 

When sharing an application, the system shall automatically share that application’s child windows and dialogs. 

2. Editing shared applications 

A host shall be able to share an application for read/write state and any child windows and dialogs of that 
application are also shared in the same state. 

3. Marking up a shared application 

The user shall be able to mark up the shared application and any child windows and dialogs. Mark up is defined 
as using any basic drawing or collaboration functionality to enhance the communication effort required by the client 
back to the host or vice-a-versa. 


G. Communication protocol 

File sharing, Internet message chatting, white board products and File Transfer Protocols (FTP) that manipulate 
and move data shall not be shared due to heavy security risks. 

Broadcast and or Multicast functionality shall use standard industry protocols. The publication/subscription 
method can be used to implement one-to-many interactive or non-interactive sharing. Broadcast is analogous to a 
radio transmitting a signal to unknown number of receiving sets or to a closed circuit TV broadcast, where any TV 
on the circuit can receive the broadcast. Multicast is analogous to publishing a magazine to a specific list of 
subscribers, which means a specific list of IP/ports addresses. 

Broadcast display sharing is always read-only to the client and the client or clients are anonymous; the sender 
does not know what clients are receiving the transmission. Therefore content security can be difficult if not 
impossible to enforce. Specifically, as the viewing community is anonymous, broadcast cannot easily facilitate 
export control. 


Multicast is likewise always read-only to the client, is delivered only to a specified list of clients, and availability 
may be restricted to levels of access (which could, for example, be defined by the firewall boundaries which limit 
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the range of a multicast). Elements of multicast which must be considered include PIM-DM 2 / PIM-SM 3 multicast 
protocols, varying ranges of low bandwidth consumption, ranges of acceptable latency, acceptable packet loss and 
artifact deduction ranges, and the establishment of user groups to facilitate export control by enabling a user to 
multicast to a specified group of users who have been cleared for export (though it must be understood that multicast 
functionality cannot enforce export control restrictions on any content). 

H. Scalability from a host to a client 

Scalability means the ability to resize a shared application’s screen ‘‘footprint’ ’ on the client machine. The system 
shall be able to automate the resolution factor from one machine display to another (without any user knowledge of 
the two machines’ display resolutions). Display size on the client shall also be controllable by the client based on a 
resolution factor or by allowing the host or even another client to resize the shared window. 

I. Recording and playback sessions 

The system shall include built-in recording capability, which will record in industry standard formats such as 
MPEG4/H.264 for playback by widely available players. 

J. Application sharing versus desktop sharing 

“Application” sharing is distinct from “Desktop” sharing. Application sharing shares a single application 
(including any child windows and dialogs) displayed on a user's workstation, whereas desktop sharing shares some 
or all of a user’s screen real estate. Most products default to desktop sharing of the host’s entire primary monitor, 
however, the system administrator shall be able to configure which is the default. 

When sharing the desktop of a multiple monitor host, the system shall allow the user to select which monitors’ 
real estate is shared. 

Both broadcast/multicast sharing and sharing direct to a specific individual or group shall be supported for both 
application and for desktop sharing. 

Some products allow the host to select the application from a list of running applications, but this can be 
cumbersome if the number of open applications is high. The system shall allow the user to select directly from 
among the active windows. 

K. System administration functions 

The administrator shall be able to monitor the sharing system for performance. The system shall prepare reports, 
message logs and statistics to troubleshoot performance and to resolve issues. 

The system administrator shall have root access as needed on the host O/S in order to resolve technical issues for 
any of the components of the sharing process. This may include access to the application server or host, the client 
machine(s), and any other component needed to setup or configure the sharing process. 

The “Statistics” function shall be gathered on: 

• Host / client latency 

• Upload speed 

• Connection, user and client counts 

A “Message Logs” function shall provide real-time data and shall include: 


2 http://www.networkdictionary.com/protocols/pimdm.php 

3 http://www.networkdictionary.com/protocols/pimsm.php 
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• Start / Stop timestamps of sharing activities between a host and client or set of users. 

• Logs of application crashes which capture as much corrupt data as possible for analysis. 

• Version number 

An “Operator / Name Directory Interface” function shall include such features as adding and removing members 
through the LDAP service (or equivalent), editing groups for user flexibility and password re-activation for locked 
accounts. Although not required, it is recommended that user registration be automated. Data that shall be recorded 
includes: 


• Name / User ID (recommend LDAP registration, but not required) 

• Group (This will help specific groups of individuals to communicate easier) 

• Initial timestamp for first time users 

• Last recorded logout timestamp 

L. Performance 

Although performance can be difficult to evaluate and manage, the system shall be able to address issues of: 

• Latency. Ideally there shall be no more than 1 second of latency between host and client. 

• Network bandwidth consumption. 

• Burden on local CPU and memory usage. 

• Frame rate. Text data shall update at a minimum frame rate of 1 Hz. Prerecorded animations and modeled 
simulations shall update at a minimum frame rate of 10 Hz. 

M. Licensing and Cost 

Cost is a factor m determining the whether to use a particular sharing application. Not all products require a 
license. Some provide a free download. Some products require a license for each separate server and each client. 
Some products are licensed on a monthly basis and some require an annual subscription. When it comes to tech 
support, as with many other products, the more you spend, the more you get. The ideal product can be downloaded 
free and implemented with minimal tech support. 

N. Handling Host Inactivity and Disconnections 

The display sharing system must be able to handle unexpected behavior to ensure a smooth user experience. 

1 . Inactive Host Sharing 

Most operating systems have lock out / screen saver / black out features which activate after a period of 
inactivity. However, the Display Sharing application shall continually push imagery out even when the host’s 
display mode is inactive and until the host deactivates the sharing. 

If a portion of the shared application’s real estate on the host is obscured by another host application’s window, 
the shared application shall still be shared completely, including the covered-over portion. If, however, there is no 
means to continue sharing a hidden application (be it screen-locked or having additional applications over it), then 
the sharing host must show what is currently active and what is not (what is updating to the client and what is 
“frozen”). 

2. Resynchronization 

As networks can go down, a host sharing application must be able to resynchronize with its clients. When 
communication is reestablished the current shared display on the client shall pick up from the host’s current feed. 
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IV. Different Customers 

In compiling the proposed requirements for this document certain customer groups at JSC were polled for input. 
Although there will be other interested customers, customer use of display sharing generally brakes down into four 
areas of interest: Flight Control Rooms, Application Broadcasting, Conference Room Collaboration, and Training 
and Simulation. 


A. Flight Control Rooms 

Flight Control Room (FCR) users require the ability to share any flight control discipline application 
(applications run on 2D XI 1-based Linux O/S) to a variety of clients, including each other’s workstations, the large 
projected screen, and, via secure remote access, to both the office environment and remote users. 

The sharing application shall support cross-platform sharing of XI 1-based displays to Windows. When a host 
shares out to the passive unmanned control center projector client, the host user must be able to remotely control the 
projector client in order for the client to interact with the shared display. For workstations with extended desktops 
(workstations with multiple monitors) all monitors and monitors’ real estate must be sharable. 


B. Application Broadcasting 

Application Broadcasting is the ability to 
publish, as read-only, any VTS application 
(including graphics and data) to the local 
MOD operations (OPS) intranet so that a 
large number of clients may subscribe to it (a 
one-to-many process) and view the data in a 
quick, secure and convenient way over the 
LAN. Any subscription process must work 
cohesively with existing certified 

applications and the operating system of the 
unmanned PC workstation that is currently 
publishing the graphics and data through the 
VTS. It is recommended that the “One-to- 
Many” technique utilize multicast protocols 
to ensure that network traffic can be 
managed for hundreds of viewers. A 
proposed test to demonstrate tins is 
described m Fig. 4. 


OTF Display Sharing test 


MCC Video System Overview 


Telemetry data 


Windows OS 
ExceedOnDemand 
VM Ware Ace 
Remote Desktop 



Figure 4. Application Broadcasting 


In this example MCC telemetry is fed into a variety of application servers, which feed into the MCC VSM. The 
VSM then converts that data for output to multiple clients, including the Scan converter and the FCR projectors. The 
Scan converter receives the output of the VSM and converts it to base digital / analog for further distribution. 
Telemetry is also fed into a virtualized PC and from there is output to the OTF LAN. OTF client PCs and IP 
projectors authenticate to the OTF LAN to receive this feed. 
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Broadcast 


Operator’s Console 


Viewer’s laptops 
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C. Conference room collaboration Conference Room Collaboration 

Conference room collaboration users 
require the ability to share any applications 
(most commonly the entire desktop) by 
pairing both subscription models (“push / 
share” and “pull / broadcast”) in a quick, 
secure and convenient way to share the 
data over an existing network. This is 
shown in Fig. 5. 

D. Training and Simulation 

Training and simulation users require 
an ability to share any flight controller’s 
application in an instructor to student led 
training exercise over the network. 

Training and simulation use encompasses 

all Flight Control Rooms sharing Figure 5. Conference room collaboration 

requirements with the addition of training- specific tasks. The instructor must be able to control imagery shared from 
their student’s entire desktop without the student bemg aware of the instructor’s actions. The instructor must be able 
to select particular monitors from the student’s workstation in order to manage the training. Instructors may also 
require the use of recording and playback 
features in order to run simulations. 
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V. Selection Process 

Different methods for moving imagery 
across the web are available. Web 
conferencing, video conferencing, desktop 
/ application sharing, remote access 
transport protocols, collaborative sharing, 
and even IPTV can execute elements of 
Display Sharing. 

A display sharing architecture could be 
any of the following types: client / server, 
multipoint control unit (MCU), peer-to- 
peer, and multicast. These methods must 
work on many existing operating systems, 
virtualization access schemes, and across 
network firewalls and the Internet and 
support sharing among small or large 
client populations. 
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Figure 6. List of Remote Desktop Software 


An enterprise solution can be difficult to describe. Vendors’ solutions were often rigid and inflexible. A vendor 
willing to adapt their product for prototyping was typically favored. To speed vendor selection it was determined 
that quick comparison charts provided by industry-driven services could suffice to compare the options available 
from vendors. Fig. 6 is a screen shot of a comparison of remote desktop software in Wikipedia 4 . 


4 http://en.wikipedia.Org/wiki/Comparison_of_remote_desktop_software#cite_ref-2 
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Fig. 7 is a screen shot of a 
Web Conference applications 5 
comparison, also in 
Wikipedia. 


Display Sharing can be 
considered a subset of real- 
time collaboration solutions, 
making it difficult to clarify 
the definition of Display 
Sharing. For comparison the 
reader may consider a 
Wikipedia-compiled lists of 
collaborative software 

packages 6 and of video 
conference applications 7 . 


Figure 7. Web Conference Products 

Rather the charts provided a starting point for vendor comparison. Licensing and 
section III, part M. 

A set of rules was developed to speed the prototyping process and explore the fundamentals of the Display 
Sharing experience. Here are some activities carried out prior to testing: 

• Surveyed top-tiered vendors for product and support data. 

• Vendors requiring monthly subscriptions and fees were eliminated in favor of those offering free trials. 

• Other vendors supplied demo versions of latest products with adjustments to accommodate our needs. 

• Excluded any audio and video functionality from testing. 

• Two (2) Windows and two (2) Linux machines were prepared for testing. 

• Did not pursue any testing of platforms other than Windows and Linux. 

• After installing, each was tested for ease of operation. 

• Used basic network analysis tools to help understand network and machine performance. 

After selecting a few products to work with, user requirements and preferences were prioritized. Table 1 shows 
these basic requirements across the top with some vendors representing different methodologies listed in the left 
column. These products were evaluated with the simple results as shown in Table 1. 
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5 http://en.wikipedia.org/wiki/Comparison_of_web_conferencing_software 

6 http://en.wikipedia.org/wiki/List_of_collaborative_software 

7 http://en.wikipedia.org/wiki/List_of_video_telecommunication_services_and_product_brands 

8 All products are capable working on a Microsoft Windows environment. 

9 Products requiring no admin support in order to install were regarded as easy to operate. 

10 Linux or UNIX-based (Linux / UNIX server to Linux or Windows clients) 

11 Requires user to participate in a single window mode. 

12 Windows-based only (Windows Server to Windows clients only) 
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While it would be best to evaluate all aspects of display sharing using commonly accepted trade study practices 
(i.e., build criteria and weigh the priorities, with complete freedom of product and feature selection), not all 
decisions were under the control of this study. The study was constrained where Linux-to-Linux and Linux-to- 
Windows transport was concerned as the OTF had selected remote access as its transport process. (This can 
remotely deliver 2D X-l 1 Linux applications to the Microsoft Windows environment.) 

Others were chosen to help develop a prototype for Windows-to- Windows sharing that could support all of the 
possible requirements of the MOD customers. This prototype had to satisfy the requirements of various customers 
as reviewed in “Differing Customers” previously. A video conference company focusing on a high end user 
experience through the Internet using a highly secure encryption process, along with very low usage of network 
bandwidth and minimal workstation CPU resources was selected for further investigation. Their Display Sharing 
architecture is based on this same video conference method utilizing a system administered gateway that includes a 
name authentication server as a means to collect and preserve members’ authorization data and a relay server for 
firewall traversal. An example of a display sharing enterprise architecture is shown in Fig. 8. 

The ability to deliver real-time adjusted pixel-to-pixel movement or pixel interpretation through a peer-to-peer 
client application allows the 
different JSC MOD customers to 
test their specific requirements. 


Video Conference products 
can couple their developed 
display sharing activities using 
the same gateway infrastructure 
(Fig. 8), as a list of security and 
maintenance benefits to 
collaboration efforts. This list 
may include: 


• Owning the sharing 
process, rather than rent 
it. (No Web-subscribed 
products, no monthly 
fees, etc.) 

• Capable of working with 

common “Name 

Authentication” Server 
via LDAP / Active 
Directory, which can be 
UDP or TCP port configurable 

• Capable of working with common “Relay Server” to help traverse through existing firewalls, which can be 
UDP or TCP port configurable 

• These systems supports single sign-on authentication to minimize group permission issues 

• These systems use an encrypted solution 

• If peer-to-peer access fails, then a UDP-to-Relay server process, followed by a TCP-to-Relay server 
process can sustain the connection. 

• File sharing / file transfer mechanism is not enabled 

• Video IP packets are not sent 

• Audio IP packets are not sent 

• Chat interactivity (including IRC) is not enabled 

• Interactive broadcasts can be password enabled for a dozen viewers (peer-to-peer only, not true multicast) 

• Collaboration annotation (mark up and review tools) is sent pixel-by-pixel (only changed pixels are sent) 

• Remote control of a client is available (requires some administrative configuration). 

• Host must be actively participating in a sharing session. Sharing is suspended if the host’s Windows 
workstation is locked or the screensaver is active. 


Display Sharing Enterprise Architecture 


Remote Sites 



Figure 8. Display Sharing Architecture 
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VI. Summary 

During the Display Sharing prototype development process most well-featured products could not fulfill all 
requirements. However, there were many advantages to pixel interpretation for this early prototype. Table 2 
provides a quick summation of those pros and cons of these capabilities as they applied to the prototype. 

Table 2. Development Insights 


Favorable actions 


Unfavorable concerns 


Ease of Operation to users 


A separate GUI can been designed to help share 
imagery by selecting the appropriate push / pull model 
that displays a quick thumbnail of the suggested shared 
space, confidently depicts active members that could 
participate in the sharing process, displays the 
recipient’s real estate for size and placement, and logs 
the actions to a message screen. The pull process 
displays Broadcasts that are currently viewable by 
permission status. Messages can be logged to a status 
area for reference. 


Currently no user feedback mechanism to 
help support this feature exists. Members 
shall have the capability to denote issues or 
concerns with specific features to a 
designated process. 


Configuration setup 


Security 


Group membership 


Sharing displays to different 
O/S 


Manipulate the existing display 


Communication protocol 


Scalability from client to client 


Recording / Playback 
Application vs. Desktop sharing 


Users may simply download the application from a local 
NASA repository; authentication automatically 
performs with local JSC credentials, ready for sharing. 

Some products use an encryption process over a Peer- 
to-Peer assigned UDP port, however if this fails, it 
automatically uses UDP Relay Server and if this fails, it 
can use the TCP Relay through port 80 or 443 
(unsecured and secured public Internet) 

Some products display both active and non-active 
participants in designated groups allowing the user to 
understand whose on or not. Some have the ability to 
configure and manage personal groups as well. 

Some are designed for all of the latest Microsoft 
Windows environments: 2000, XP, 2003, Vista, and 
Windows 7. 


Annotation features allow the host and recipient to 
communicate with chosen colored scribble pen and text 
features on the designated shared real estate. The ability 
to quickly erase the annotation resets the 
communication for more whiteboard like updates. 


Some Broadcast features are controlled by a password 
for a dozen or so interactive clients to participate with. 


A few products feature a host to remotely change the 
size and placement on the client of the prepared shared 
real estate by previewing the layout for each selected 
client. Once shared a client can then move or resize the 
shared image to suit. 


Some products have the ability to record / playback. 
Applications can be selected based on a list of existing 
applications currently located on the viewable desktop 
or simply by selecting the appropriate window to be 
shared. Some desktop features can be stretched to 
accommodate many monitors or a region of real estate. 


Some products require that the users must 
have root access to download, otherwise 
permission is denied. This can be 
cumbersome to administer. 

Offsite communication tactics may require 
VPN traversal (if no Firewall traversal 
solution exists) that may indeed demonstrate 
slower performance characteristics. 

Some do not currently use all authentication 
features that would help dictate permission 
concerns with specific groups. 
Automatically embedding active directory 
features would help. 

Some Windows applications do not support 
Linux/UNIX and Apple MAC O/S. Web 
Browser plug-ins may be a way to 
incorporate temporary resolutions, but will 
need to include cross-platform solutions. 
Action Buttons can appear within the 
controlled shared real estate at times, thus 
disallowing the user to interact under those 
features. Color and text palettes are usually 
pretty weak with no control. Some erase 
features usually erase all annotations, not 
separately. Most do not capture annotations 
for storage and playback. 

Most do not support a true multicast for 
one-to-many subscribed viewers. Request is 
generally stated for more than a few 
hundred specific viewers. Security does not 
have the ability to disable any broadcast. 
When receiving a multiple-monitor 
broadcast clients should select a specific set 
of monitor(s) from among the monitor 
images shared from the host and exclude 
others, but some products only dictate the 
primary desktop as the only source of the 
monitor images shared. 

Most products do not support this feature. 
Most products dictate the desktop sharing 
function by presenting the primary monitor 
as a source of shared real estate. Some 
products do allow the controllable area to be 
stretched, however this process does not 
maximize the viewing portion for the 
recipient to choose which monitor or set of 
monitors that exist from the host 
broadcasting its desktop. 
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Favorable actions 


Unfavorable concerns 


System Administration 
functions 


Performance 


License & Cost 


Inactive Host Sharing 


Some demonstrates network statistics, shared 
connection statistics, logged messages, and a means to 
adjust specific permissions to group members. 


A few can support many Flash animated playbacks that 
could result in performance of over 20 Hz (frames / 
second), thus allowing latency to be minimal. 
Application or Desktop sharing bandwidth consumption 
is minimal due to pixel adjustments only, thus capable 
of less than 100 kb / sec bandwidth. Some can have a 
low CPU consumption as well. 

A yearly maintenance fee allows up to hundreds of 
members to communicate through a repository for 
permissions and activation was best suited. 

Ability to shut down the sharing process when the host 
screen itself appears to be blacked out through locked 
screens or power savings. 


Most do not provide a significant factor to 
group specific individuals of an Active 
Directory listing. Some products allow 
members to see all active memberships 
within designated groups, thus providing 
confidential detail. 

As more recipients view a particular host's 
shared imagery, most products lacks 
assistance with CPU performance. 
Certainly not recommended for raw or true 
video sharing, although this can be coupled 
with a third party performance accelerator to 
enhance performance, but they tend to cause 
more harm than good. 

There will be a specific dollar amount per 
year for maintenance costs on any of the 
supporting servers. 

The user community would like the sharing 
process to continue without hesitation from 
the host. 


The OTF continually investigates this prototype process by enhancing and upgrading the process based on our 
experience and feedback in order to continually improve the prototype. Development of the prototype has proceeded 
with the awareness of some limitations. 


• As of this writing, many products support Microsoft Windows based sharing only. There are web plug-ins 
in development to help support other operating systems. The Mac operating system can be integrated with 
Windows emulators like Fusion and Boot Camp. There are no current Linux or UNIX available. 

• Some products application broadcast feature only allows about a dozen viewers and uses a peer-to-peer 
connection process. This may be described better as a publication of only a dozen books and only a dozen 
subscribers can view the publication. This is not a true Multicast, which acts like the radio transmissions 
that are picked up by any amount of receivers. Some products broadcasts could be allowed to accept a 
password controlled view for the client, although the host may need to turn the client’s interactivity 
mechanism off. It may be necessary to include additional broadcast features for the one client. 

• Be aware that specific Windows application functions can tend to bleed into the Host controlled real estate. 
Windows can be configured to turn off specific effects like; the Shadow under menus, the Window contents 
while dragging feature and the Fade (transparent) effect on transitioning effects for menus and tooltips - to 
help minimize the undesired sharing artifacts. Using a pixel interpretation process can help distinguish 
between a live update and no change, thus providing a benefit of low packet traffic on an IP system. 
However, if any of the active shared real estate is obstructed by other windows or effects, then the shared 
imagery may be interrupted. Although this is not optimal, some products can clue the client / user by 
conveniently shading the desired viewing area where any updates are not coming through, so that the client 
user may ask the host to move the obstructing window. 

• Although a third party “Performance Accelerator” can improve performance, it can also impede video 
setting configurations for other visual / imagery products such as; Ultramon 13 , VLC 14 , any VNC 15 product 
or window management tool 16 . It is recommended that any window manager products present be tested for 
possible conflicts or interference. 

• Collaborative “Actions Buttons”, which can control and annotate the shared region, can be a nuisance by 
obstructing valuable real estate that may require interaction. The testers prefer that any Action buttons be 
hidden and instead behave like the Microsoft Windows Remote Desktop mechanism that appears and 
disappears depending on mouse rollover. 

• Most products do not support a mechanism for “Export Control” compliance (US government secured 
content) other than perhaps utilizing the Organizational Units (OU) of the Active Directory, where the OU 
helps describe permission levels for a particular group of users. 


13 Ultramon, from Realtimesoft, a desktop monitor management tool, http;//www.realtimesoft.com/ultramon/ 

14 VLC, from VideoLAN, a media player for network streaming protocols, http://www.videolan.org/ 

15 VNC, http://en.wikipedia.org/wiki/Virtual_Network_Computing 

1 6 http :// en. wikipedia . org/wiki/W indowmana ger 
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VII. Conclusion 

While there are many products that can provide solutions which possess some attributes / features of Display 
Sharing, there may be few products that can satisfy all requirements. Desired attributes and features must be 
prioritized in order to determine which products can best meet known requirements. A prototype was developed to 
provide Display Sharing strengths and weaknesses. Proving the concepts of Display Sharing and demonstrating 
possible tools to the MOD community has allowed us to uncover invaluable information to help MOD users perform 
their tasks quickly, efficiently and with better cost effectiveness. 

With the advent of Digital Video techniques, IPTV and many network streaming protocols within the JSC 
network infrastructure. Display Sharing can be overlooked and regarded merely as a minor tool to visualize ideas. 
While the ability to share screen information through many types of IP session based screen sharing tools provides 
you duplicated data and graphical updates, clients do not receive a pure pixel interpretation from the host to a client 
or to set of clients. Pixel interpretation allows the client to not be reliant upon the specific application that delivers 
the graphical update. However, a Linux- to- Windows graphic transport (a remote accessible session) coupled with a 
Windows-to-Windows display sharing product, an alternative method was introduced to the JSC community 
offering significant and thought-provoking options for successful collaboration via shared displays and applications 
across the network. 
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Introduction 



• MOD looks for innovative ways to reduce costs 

• Study alternative architectures for the current Video 
Tra nsp o rt syste m ( V15) 

• Current V15 satisfies MOD requirements to share 
display imagery in Flight Control Rooms (FCR) 

- Sharing to Lange Projector Screens 

- Pictune-in-Picture Windows 

- Otherbackanea control rooms 


• Preliminary additional requirements 

- Ability to share a screen orapplication to one ormany 

- Ability to scale imagery to target's screen resolution & size 

- Ability to easily configure and operate 

- Ability to maintain high level of performance & security 
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Introduction 



• Wha t is Disp la y Sha ring ? 

- Not intended to be an alternative to IP video 
systems 

- Delivers more than just video 

- Need to understand the existing video 
infrastructure 

- Lookfora Design Approach 

- Customer driven requirements 

- The Selection Process 

- Collection Summary 
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Video Infrastructure 



Using a variety of sources 
ranging from standard 
& high def cameras 
from eitherthe ground 
orin space and 
differing computer 
displays, a video switch 
system can route 
imagery to multiple 
types of rec ip ients using 
the existing RF cabling 
and BNC connectorVT5 
that has been 
developed for many 
years 
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Video Infrastructure 



A well proven IP Video 
system has the ability to 
duplicate many of the 
current requirements of 
the VT5and could be 
more cost effective. 

However specific image 
sharing would require 
additional configuration 
and maintenance that 
can be cumbersome, 
slow and inconvenient. 


Generic Video IP Switching System 

Legacy "system " 







Decoder 


VGA 


Encoder 


(STB) 


Converter 

— ► 




Stand Alone 
TV/Monitor 



Legacy Camera 


Server/Workstation/Video 
On Demand/etc. 
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Design Approach 



• Develop a prototype using commercial off-the-shelf 
(C015) products to demonstrate its feasibility 

• Use freely available tools and comparison charts 

• Share a display or specific application from one 
workstation to anotherwithin Mission Control Center 
(MCC) 

• Use existing V15to help seed a list of requirements 

• Include security IP requirements 

• Only software solutions were considered - no 
access to hardware costs 

• No 3D rendering wasconsidered due to costs 
although sharing 3D graphicswould impact results 
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Design Approach 



• A list of requirements based on initial testing 

• Ease of operation to users 

• Configuration setup 

• Security 

• Group membership 

• Sharing displayswith other ope rating systems 

• Manipulate the display 

• Communication protocol 

• Scalability from a ho st to a client 

• Recording and playback sessions 

• Application sharing versus desktop sharing 

• System administration functions 

• Performance 

• License and Cost 

• Handling Host Inactivity and Disconnections 
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Diffe re nt C usto me rs 



• Flight Control Rooms 

• Application Broadcasting 

• Conference Room Collaboration 

• Training & Simulation 


J SC /MOD - Display Sharing 


8 


April 26 - 30, 2010 



Application Broadcast 


OTF Display Sharing test 


Application 

Servers 


MCC Video System Overview 


Telemetry data 


Windows OS 
ExceedOnDemand 
VM Ware Ace 

Remote Desktop 


i 


PC Clone 


Maps 


Satellite 


VTS 


Clocks 


Robotics 


Weather — 
OTF 1 



Video 

Switch 

Matrix 

(RGB/ 

Digital) 


OTF IP 
Projectors 

OTF Client 
PC 


OTF Client 
PC 
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Conference Rooms 



Conference Room Collaboration 



Broadcast 


| 

Operator’s Console 






Share 





Presenter’s laptop 
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Selection Process 



• Different methods to move imagery 
acnossa secured IP network include: 

- Web Conferencing 

- Videoconferencing 

- Desktop or Application Sharing 

- Remote Ac cess Transport protocols (session-based) 

- Collaborative Sharing 

- IPW 

• Display Sharing Architectures could be created as: 

- Client/Server 

- Peer-to-Peer 

- Multicast 
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Selection Process 



• Any of these methods must work on: 

- Existing Operating Systems 

- Virtualization access sc hemes 

- Across Network Firewalls and the Internet 

- Support up to large client populations 

• An Enterprise Solution can be difficult 

• Vendors' solutions we re often rigid and 
inflexible 

• Used various comparison charts to 
quickly determine suggested products 
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Selection Process 


• Although Wikipedia is not considered 
factual information, it can be a fairly 
quick source of analysis. 

• Several Wikipedia charts exist today 
comparing several products including: 


- Collaborative products (hM ://en.wikipedia.ora/wiki/List of collaborative software ) 



VideO Conference ( http://en.wikipedia.oro/wiki/Ust of video telecommunication services and product brands ) 
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Selection Process 



• Setof rules was developed to speed the 
prototyping process and explore the fundamentals 
of the Display Sharing Experience. 

- Surveyed top-tiered vendorsforproduct and support data. 

- Vendors requiring monthly subscriptions and fees were eliminated in favor 
of those offering free trials. 

- Othervendorssupplied demo versions of latest products with adjustments 
to accommodate ourneeds. 

- Excluded any audio and video functionality from testing. 

- Two (2) Windowsand two (2) Linux machineswere prepared fortesting. 

- Did not pursue any testing of platforms otherthan Windowsand Linux. 

- After installing, each wastested forease of operation. 

- Used basic network ana lysis tools to help understand networkand 
machine performance. 
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Selection Process 




Display 

Linux 

Apps 

Latest 

Encryption 

App. 

Sharing 

App. 

Children 

Shared 

Display 1 

Window 

Applications 

Easy 

Actions 2 

Latency 

Performance 

Resolution 

Network 

Bandwidth 

Remote 3 

Access 

Y 

Y 

Y 4 

Y 

N 

N 

< 1 sec 

Nominal 

Nominal 

Remote 5 

Access 

N 

Y 

N 

N 

Y 

N 

< 1 sec 

Nominal 

Nominal 

Video 

Conference 

N 

Y 

Y 

N 

Y 

Y 

< 1 sec 

Better 

Better 

Remote 

Access 

Y 

Y 

N 

N 

Y 

N 

<1.5 sec 

Below 

Nominal 

Web 

Conference 

N 

Y 

N 

N 

Y 

Y 

<1.8 sec 

Well Below 

Nominal 


n All products are capable working on a Microsoft Windows environment. 

121 Products requiring no admin support in order to install were regarded as easy to operate. 
121 Linux or UNIX-based (Linux / UNIX server to Linux or Windows clients) 

141 Requires user to participate in a single window mode, 
is Windows-based only (Windows Server to Windows clients only) 
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Selection Process 



• Another OIF study selected the remote 
access transportation pnocessasthe Linux- 
to -Windows solution. 

• A Video Conference product foe using on 
high end user experience waschosen to 
develop a prototype for the Windows-to- 
Windows Solution 

- Highly secure encryption process 

- Very low usage of network bandwidth 

- Required minimal workstation CPU resources 

- Authentication Serverto collect member authorization 

- Re la y Se rve r to traverse through network firewalls 
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Selection Process 
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Selection Process 



• Additional security benefits include: 

- Owning the Sharing process(No web-subscription required) 

- Capable of working with Active Directory that is port configurable 
through eitherUDP, TCP orSSL 

- Capable of working with Relay Server that is port configurable 
through eitherUDP, TCP orSSL 

- Supports single sign-on authentication for minima I group 
permission issues. 

- Encrypted Solution 

- No File Sharing / File transfer 

- No Video orAudio specific packetsare sent 

- Collaboration annotation efforts a re sent via pixel-to -pixel process 

- Remote Control is available if desired 

- Flost must be actively participating in sharing process. Sharing is 
suspended while screensaver is active. 
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Summary 




Favorable Actions 

Unfavorable concerns 

Ease of Operations 

A simple GUI providesthe 
appropriate push / pull model 
processes. 

No user feed back mechanism is in 
place. 

Configuration Setup 

Users a re automatically 
authenticated using local Active 
Directory. 

Some products require rootaccess 
to download. 

Security 

Encryption over Peer-to-Peer using 
UDP / 1C P / SSL Relay Serverfor 
firewa lls. 

Offsite tactics may require VPN 
traversal, which will slow 
performance. 

Group Membership 

Some pnoductsdo display both 
active and non-active participants. 

Some do not use all of the 
authentication features within an 
active directory. 

Sharing Displays to different 0/ S 

So me ma inta in a II of the la st 
decade of Windows support. 

Not very many applications 
support both Unux/ UNIX and 
Windows. 

Manipulating the existing display 

Annotation orwhiteboard features 
a No w the host a nd c lient to 
collaborate. 

Action buttons, erase featuresand 
color palettes behave awkwardly. 
No storage or playback features. 

Communication protocol 

Some Broadcast features a re 
controlled by a password fora 
dozen or so interactive clients. 

Mostdo notsupporta true 
multicast for a few hundred clients. 
Security wishesfor disable function. 
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Summary 




Favorable Actions 

Unfavorable concerns 

Scalability from client to client 

Few products feature a host 
remotely changing the size and 
placement for sharing with clients. 

Multiple monitors should be 
included within the Desktop real 
estate. 

Recording / Playback 

Some productsdo include the 
ability to record and playback. 

Most productsdo not support this 
feature. 

Application vs. Desktop Sharing 

Applicationsordesktopscan be 
selected for sharing. Mostselect 
from a list of available applications. 

Most products dictate the desktop 
sharing function by presenting the 
primary monitor only. 

System Administration functions 

Some demonstrate network 
statistics, shared connection 
statistics, and logged messages. 

Most do not provide a significant 
factorto group specific individuals 
of an Active Directory listing. 

Performance 

Through some pixel adjustments, 
bandwidth and CPU consumption 
can be quite low. 

Not recommended forraw video 
sharing, although coupled with 
performance accelerator may. 

License & Cost 

Site-wide licenses can be cost 
effective with a yearly 
maintenance cost. 

Some providersare rather 
expensive forthe yearly costs. 

Inactive Host Sharing 

The ability to stop the sharing 
processwhile the host is screen 
locked orhaspowersavings. 

Some customers would like the 
sharing process to continue 24/ 7 
without resynchronization issues. 
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Summary 



• OTF is continually investigating and developing the 
Windows-to-Windows prototype with userfeedback 
Some limitations include: 

- No Linux/ UNIXorApple support available 

- No multicast pnocessfora one-to-many broadcast 

- Some Windows application functionscan bleed into Host 
controlled real estate, and would require Windows tooltips to 
minimize undesired sharing artifacts. 

- Application sharing can be halted by obstructing applications 
and may require an additional feature to inform the client 
(obstructions may offer no updates to shared real estate). 

- Third party Performance Accelerators can hinder sharing process. 

- Collaborative “Action Buttons" can be a real estate nuisance. 

- May want to directly incorporate Active Directory functions as a 
mechanism to provide Export Control compliance. 
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Conclusion 



• Few productscan satisfy all requirements. 

• A prototype wasdeveloped and shared throughout the 
JSC community with various customers. 

• Proving and demonstrating quick, efficient and cost 
effective conceptsof Display Sharing to the J SC 
community has provided invaluable information. 

• Pixel-to- pixel movement or pixel interpretation allowsthe 
client to not be so reliant upon a specific application 
thatdeliversgraphical updates. 

• A Linux-to-Windows remote access session coupled with 
the Wind ows-to-Windows display sharing product can 
be considered an alternative method forthe J SC 
community with thought provoking optionsand 
successful collaboration via shared displays. 
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Questions 
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